Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

spec: proposal for terminology #101

Open
wants to merge 1 commit into
base: eei-v2
Choose a base branch
from
Open

spec: proposal for terminology #101

wants to merge 1 commit into from

Conversation

ehildenb
Copy link
Collaborator

@axic, @chfast, and @poemm, I've tried to specify the terminology we've discussed. Need feedback on the EVMC bullet point, and on the overall naming of things.

@poemm
Copy link
Contributor

poemm commented Jun 22, 2018 •
edited
Loading

More generally, it seems that we want Clients and VMs to both be swappable by each exposing only an API. I can envision three common cases, which follow.

  1. Client <--API--> VM
    The VM provides all behavior required by the system, and can communicate over the two-way API exposed by both the client and VM. This is the case with EVM.

  2. Client <--API--> VM extension <--API--> VM
    The VM can't provide all behavior required by the system, or it can't call/expose the API. Then it needs an extension glued on which can do this. This the case with Wasm, since Wasm exposes a embedding API and can call host functions in the extension.

  3. Client <--API--> VM+extension
    This is a mixture of the two above cases. The VM alone does not include all desired behavior/interfaces, but it has mechanisms to be internally extended to a state in which it does. This is the case for a Wasm VM containing an EEI module instance, and which exposes the Wasm embedding API to the client.

@ehildenb Are you trying to model one of these cases?

@ehildenb
Copy link
Collaborator Author

ehildenb commented Jun 23, 2018 •
edited
Loading

Note, I think we have agreed prior to call the actual underlying computational thing the "execution engine", and the combination of that + the client the "VM".

So, I would say it's closer to:

Client + EEI method implementations <--EEI--> execution engine

chfast
chfast reviewed Jun 23, 2018
View reviewed changes
spec.md

**Ethereum Client**: Code which can interact with the blockchain (read/validate and sending transactions).
**EEI method**: A method exposed by the Ethereum Client to the execution engine for interacting with the blockchain state.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wander maybe "function" would be more familiar name.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to avoid the word "function" because they aren't functions in the mathematical sense. I think "method" or "procedure" is closer, in the sense of methods from OOP languages like Java which can alter the state of the surrounding context.

spec.md

**Ethereum Client**: Code which can interact with the blockchain (read/validate and broadcasting transactions).

**EVMC**: The *Ethereum Virtual Machine Connector* (correct name?) refers to one of (**TODO: Which one?**):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's API (C language) containing both API for VM and EEI.

Maybe I should physically separate both for clarity?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the full name for acronym EVMC is here: https://github.com/ethereum/evmc

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so would:

EVMC: The Ethereum Client-VM Connector API is the C implementation of the EEI.

be an accurate description?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, good idea @poemm, I'll make all these definitions links when appropriate.

@poemm
Copy link
Contributor

poemm commented Jun 23, 2018 •
edited
Loading

A comment which may confuse the conversation. Feel free to ignore.

When someone reads "Ethereum Environment Interface", it needs explanation. "Ethereum Client-VM Connector API" is more self-explanatory, but the word "Connector" is unnecessary and adds the confusing "C" into the acronym.

Generalizing the convention from EVMC, maybe we can consider using Client API for the Execution Engine, Execution Engine API for the Client, and Execution Engine Extension for the Client. Then we can substitute specific cases like Ethereum API for Wasm, EVM API for Ethereum, and Wasm Extension for Ethereum. Then we can say: EVMC implements the union of Ethereum API for EVM and Ethereum API for Wasm, and EEI specifies Wasm Extension for Ethereum.

This convention can include versions, e.g. Ethereum2.0 API for Wasm1.1.

I know these names need work, but they are more self-explanatory and future-proof.

@lrettig
Copy link
Member

lrettig commented Jun 24, 2018 •
edited
Loading

I like what @poemm says here because Acronyms Seriously Suck

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@chfast chfast chfast left review comments

@poemm poemm poemm left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@ehildenb @poemm @lrettig @chfast